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rrnss-Rcference to Related Applications 

This application claims the benefit of priority of U.S. Provisional Patent Application 
Serial No. 60/21 1,719, filed on June 15, 2000, and is related to Applicant's co-pending 
applications, identified as Attorney Docket Nos. 878-006, 878-007, 878-008 and 878-011. Each 
of these applications, including the above-referenced provisional application, is incorporated by 
reference herein as fiilly as if set forth in its entirety. 

Field Of The Invention 

This invention relates to a system and method for processing and managing data 
corresponding to RFP's ("requests-for-proposal"), and more particularly, to an on-line system 
and method for tracking the performance of a selected RFP vendor or buyer. 

Background nf the Invention 

Many goods which are purchased by a large industrial entity (e.g.- utility and/or energy 
companies) may be purchased over-the-counter. These type of goods are typically employed by 
the industrial facility for the maintenance, repair and operation of the facility, and are often 
referred to as "MRO" products. Since these products are relatively common, they may be 
purchased from a catalog. Alternatively, they may be purchased on-line in the typical fashion, 
whereby a user visits the website of a vendor and orders the product described on the website. 
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However, there are many goods which can not be purchased over-the-counter by a large 
industrial entity. Highly engineered goods typically fall into this category, as they are very often 
required by an industrial entity but can not be purchased in the typical on-line fashion descri^^^ 

above. Highly engineered goods, by definition, must meet an industrial entity's specific, and 
often unique, engineering requirements. Thus, they can not be purchased fromacatalog or on- 

line. 

Instead, highly engineered goods are typically procured by an industrial entity by 
creatinga,^uest.for-proposal(referredtohe.inaflerasan»RFP").TheRFPdescribesthe 

unique engineering specifications that are required u> be incorporated in dre product. The RFP is 
then supplied to vendors that are deemed capable of ntanutaeturing the product in accordance 
„id, the required engineering specifications. The vendors' proposals are then submitted to d>e 
industrial entity for its consideration. 



g While the above-described RFP system is very commonly employed by industrial 

1 entities, there is currently no system or method which provides an opthnal workflow and 

2 collaboration capabilities in the creation, management and tracking of RFP's in an on-line 
enviromnent. Thus, there exists a need for such a system and method. 



Siimmarv Of T hft Tnvention 

m present invention, in accordance with one embodiment, provides a system and 
rnethodfor tracking the performanceofan RFP vendor in an on-line enviromnent, and forusing 
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a,eperfonna„cedaUco,.pUedbytesys.™i,.orier.odett™nefl,evendo,-seligibilin-.o 
««« other RFPs in the to. Although not Itaited thereto, the system and method of the 
present invention is particularly well-suited to utility and energy companies, which often require 
highly engineered goods made to unique specifications. For the purposes of this application, the 
entity making an RFPisrefe^edtohereinafterasa-purchaser-andtheentity which respondsto 

the RFP and performs the project r^uired by the RFP is referred to hereinafter as a "vendor". 1. 
is noted, however, that the pt^en, invention is not intended to be limited in scope to any 
particular type of pmohaser or vendor, nor to any particular type of good. 

to a preferred embodiment, the system comprises a network of at least one purchaser 
terminal for entering RFP data and a network of at least one vendor terminal for entering 
proposal data. The RFP data may include, but is not limited to, dre name and type of product 
desired, the unique engineering specifications that the product must meet, as well as scheduling 
,™s,paymen,tenns etc. Ue proposal data may include,but is notlimitedu,.the name and 

type of product which is available, an explanation of how die available product meets the 
specified engineoing requirements, the price and availability of tite product, etc. 

The system also comprises a processor having a web server, which is configured to 
maint^nanaddressable web site forproviding interfaces tousersofthe purchaser and vendor 

terminals. The processor comprises an a^lytics module. TT,e analytics module is configured to 
generate no.iflcationmessagesU,avendor at various stages of anRFP project, inquiringwhetiter 

the vendor is going to meet interimdeadlinesduringthe project. T^eRFP vendor respondsby 

transmitting notification response messages to the system, indicating that the decline has. or is 
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going .0 be «t. or else indieartng fta. the deadline is not going to be met Tbe system of the 
present invention then distributes the notification response messages to others are effected 
by the vendors timely performance, such as other vendors involved in the project or persons at 
fte purchaser company that are responsible for monitoring the vendor. 

The analytics module is also configured to store in a vendor performance data storage 
module a record of the vendor's notification response messages. Data from the vendor 
performance data storage m«lule is then employed by the processor in order to detemtine a 
vendor's eligibility to receive &ture RFP broadcasts, insuring that vendors that bid on RFPs 
meet a minimum standard of reliability. 

Krirf nwcriir llT" "rawtMS 

The subject matter reg^ded as the invention is parUcularly pointed out and distinctly 
claimed in Are concluding portion of the specification. The invention, however, both as to 
organization and method of operation, together with features, objects, and advantages titereof 
may bestbe understood by reference totiae following detailed description when read withthe 

accompanying drawings in which: 

Figure 1 is a diagram that illustrates the saUent features of an on-line RFP management 
system, in accordance with one embodiment of the present invention; 

Figure 2 is a diagram that illustrates the storage arrangement of scheduling data in a 



scheduling data storage module, in accordance with one embodiment 



Figure 3 is a diagram that illustrates the storage arrangement of notification data in an 
eventnotification data storage module, in accordance with one embodimentofthe invention; 

Figure 4 is a diagram that illustrates the storage arrangement of vendor performance data 
in a vendor performance data storage module, in accordance with one embodiment of the 

invention; 

Figure 5 is a flowchart that illustrates the steps that are performed by an analytics module 
to generate notification messages toavendor and to receive and distribute the vendor'sreponses. 

in accordance with one embodiment of the invention; 

Figure 6 is an interface that is employed in order to display scheduling data, in 
accordance with one embodiment of the invention; and 

Figure 7 is a flowchart that illustrates the steps that are performed in order to employ 
vendor performance data to determine the eligibilityofvendors to receiveabroadcastofan RFP, 

in accordance with one embodiment of the invention. 

n«.tailed Pes irir^'"" ^^'^^'^ Tnvention 

In accordance with one embodiment, the present invention is directed to a system and 



method for creating, managing and tracking RFP's in an on-line environment. The salient 
features of the present invention according to one embodiment, are shown in Figure 1. Although 
not limited thereto, the present invention is advantageously employed by utility and energy 
companies that require highly-specialized or engineered products. 

Figure 1 illustrates a communications system 100, in accordance with one embodiment of 
the present invention. In the embodiment shown, vendor terminal 102 and purchaser terminal 
104, such as personal computers, hand-held devices or the like, are coupled to Internet 106. Also 
coupled to Internet 106 is processor 108. 

Processor 108 comprises web server 142 which is configured to maintain an addressable 
web site. Processor 108 also comprises viewer display interface 140 that provides an interface 
for users of the computer terminals to communicate with processor 108, as will be described 
further below. System controller 144 is coupled to web server 142, and controls the operationof 

processor 108. Processor 108 also comprises modules which perform various operations 
(although it is noted that these modules need not be discrete components but may instead be any 
combination of components, or software, which provide the desired functionality described 
below). 

Aooordmg to one embodiment of the invention, processor 108 comprises purchaser team 
builder module 1 10, which is configured to receive and process request data irom one or tnore of 
the purchaser terminals. Purchaser team builder module 1 10 provides a workflow dtat enables 
the users of the one or more purchaser terminals to collaborate in d,e creation of an RFP. 



Processor 108 also comprises vendor team builder module 1 1 2, which is configured to 
receive and process proposal data from one or more of the vendor terminals. Vendor team 
builder module 1 1 2 provides a workflow that enables the users of the one or more purchaser 
terminals to collaborate in the creation of a proposal in response to the purchaser's RFP. 

Processor 108 may also comprise broadcast module 114, which is configured to 
broadcastthe requested data toadesirednumberofvendors. Broadcast module 114 may also 
compriseabroadcast rules module 114a and a broadcast population module 114b. Inapreferred 
embodiment, the broadcast rules modulelMa comprises the requirements that must be met bya 

particularvendor inorderto receive thebroadcast of an RFP. The broadcast populationmodule 
114b, on the other hand, is configured to store data corresponding to allofthe vendors that may 

be used. 

Processor 108 may also comprise proposal analysis mod* 116. Proposal analysis 

module 1 16 is configured to receive and process proposals that are received from various 
vendorsand.advanu,geously,.oge„era.eaproposal*laUonteiden.ifiesfte vendor which 

is most suirtle to receive the order. Processor 108 may also comprise a negotiation module 
1 18. which is configured to enable the purchaser and vendor to communicate directly with each 
other via e-mail in order to negotiate the terms of the order. 

m a preferred embodhnent, processor 108 also comprises analytics module 120. 
Analytics module 120 is configured to traclc a project by ascertaining its progress at various 
stages otprodnction. Ue ar^lytic data generated by analytics module 120 may advantageously 



be mined for various reasons. For instance, data corresponding to a particular vendor's on-time 
delivery performance may be processed for use by the broadcast module 114 in order to 
determine whether the vendor will receive future RFP's via broadcast. 

Processor 108 may also comprise template manager module 122. Template manager 
module 122 is configured to enable a user to either create new templates (e.g.- engineering 
templates, legal templates, etc.) or to select from existing templates from a template library. The 
templates that are generated by template manager module 122 provide a predetermined format 
for storing data entered by users, thereby allowing efficient storage and evaluation of pertinent 
RFP data. 

Processor 108 is also coupled to database 150, which is configured to store data. 
Processor 108 accesses database 150 in order to retrieve stored data when necessary. Database 
150 may comprise scheduling data storage module 152, which stores data corresponding to the 
scheduling of a project. Advantageously, scheduling data storage module 152 stores data 
corresponding to the events which are required to be completed by a vendor in performing a 
project. Scheduling data storage module 152 also stores relevant dates for each of the events 
during a project, and defines the order in which the events occur. Figure 2, which is explained in 
detail below, illustrates the format of scheduling data storage module 152, in accordance with 
one embodiment of the present invention. 

Furthermore, database 150 may comprise event notification data storage module 154, 
which stores data corresponding to the notifications or alarms that are required in order to keep 



pa«ies apprised of»,eprog«ssofaparticularp™jeotAdva„.ageously,eve„.„o*^^^^ 
storage module 154 sK,«sdaUcon«ponding«>tep«so„ or personsWcan provide 
,„forma,io„regarfin8*eprogressofd,eeven«ofaproiee..Eve„.BO.mcatoda.as»ra^ 
„dulel54isaccessedbyp™cessorl08a,relev».mues»nesinorderu>de.enninefte 
progressof*eproieolandU>—oa«progress„pda.es»4erelevan.partics. Figures. 

which is explained iu detail below, illustrates .he fomat of event notifieation daU storage 
n,odule 154, in accordanee with one embodiment of the present invention. 

Finally, database 150 may also comprise vendor performance data storage module 156, 
whichs,oresda.acorrespondi„g.oeachvendofsperformance.Ge„erally,vendor performance 

data storagemodule 156 main.ainsa-.pori card" oteachvendofsperformance(e,g..,he 

number of times thataprojectperformedby the vendor was completedontime. renumber of 

.imesthatthe vendor missedamilestone.etc.).Modulel56 may storeperfomancedatarelating 

toacurrentproiectandtoproiects previouslyperfonnedbyfte vendor. Figure4. which is 

explainedin detail below.i.lustratesthefonna.ofvendor performance daustorage module 156. 

in accordance with one embodiment of the present invention. 

AS previously mentioned, FigureZillustrates the format of scheduling data storage 

module 152, in accordance with one embodiment of the present invention. Schedultng data 
storage module ,52 stores data eorrespondingtotheevents Which are recuiredtobe completed 

hyavendorinperformmgaproject. For instance, Figure2showsaneve«.fleld 201. Even, 

fle,d20.s.oresa,is, of events, suchas-Fabrica^ComponentA-.-Fabricate components", 

"tetall Component A in Component B", "Ship to Purchase^', 
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Fig„« 2 also shows scheduled start da« field 202, which stores the date on which the 
corresponding event is scheduled to be started. start date field 203 stores the date on 
which the corresponding event actually is started. Scheduled completion date field 204 stores 
fte date on which the corresponding event is scheduled to be completed. Acn.al contpleUon date 
f,eld205 stores thedateonwhich.hecorrespondingeventach.lly is completed. Fields 203 and 

205 are updatabic in order to reflect dte progress of the project. The data in d,e fields of this 
module may be entercdbyapurchasenormayinsteadbe automatically populated front data in 

templatemanager module 122 or negotiationmodulellS. The manner in whichdataisstoredin 

templatemanagermodule .22 or negotiation moduleUSisdiscussedinApplicantWpending 

applications. 

scheduling data storage module 152 also provides in field 206 a list of other events that 
are directly c.tcctcdbytheprogressoftheevent.Particular,y,field206 of module 152 lists any 

other event which is notstmeduntil^e completion oftheprcsent event. For mstance.usmg the 
example cited above, the cvents-FabricateComponentA-and-FabricateComponentB-may 

be worked on concurrently. However, moduie 152 also establishes via field 206 that 4e even, 
...nstallComponentAinComponentB-cannotbeperformedunUlbothofthese previous steps 

are completed. Additionally.module 152 establishes thatfteevent-Shipto Purchaser cannot 

be performed unttl Component A is installed in Component B. The establishment of dtese 
relationships andthemaintenanceof dates for eaehis commonlyreferredto asa-Critical Paft" 

„,hod. Tire manner by whichthese dates are updatedand conveyed totherelevantparties is 
discussed in comiection with the flowcharts below. 
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As mentioned above, Figure 3 illustrates the storage of notification data in an event 
notification data storage module 154, in accordance with one embodiment of the invention. For 
instance, Figure 3 shows event field 301 , having events corresponding to those stored in 
scheduling data storage module 152. Figure 3 also shows date field 302, which stores the date 
upon which a notification relating to the event is to be transmitted to the vendor. Contact data 
field 303 comprises the contact information for a person at the vendor who is most 
knowledgeable about the date upon which the event is to be completed, while distribution data 
field 304 comprises additional contact data for transmitting the vendor's response to other 
persons that need to know the relevant dates concerning the event. This contact information may 
be entered separately, but is preferably automatically populated by data from team builder 
modules 1 10 and 1 12, the operation of which are discussed in greater detail in Applicant's co- 
pending applications. 

Figure 4 illustrates the arrangement of data in vendor performance data storage module 
156, according to one embodiment of the present invention. As previously mentioned, vendor 
performance data storage module 156 stores data corresponding to each vendor's performance. 
Specifically, vendor performance data storage module 156 maintains a record of each vendor's 
performance for a current project, so that the vendor can be reminded to increase productivity. 
In addition, vendor performance data storage module 156 maintains a record of each vendor's 
performance for previously-completed projects, so that the purchaser can determine whete 

vendor is suitable to receive a new RFP. 

Figure 4 shows a vendor field 401, which comprises a list of the vendors in the system. 
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Comp,««.projec.da«secta402 comprises da.aco,respo„diag.oproiec.sfta,4e vendor 
hasoo™p,e.edin*epas..This,ypeofda.mayinduae*e„a.eofap,oject,*eda.e*a.a,e 
p„jec. was s«eda„dcon,p,e.ed>eprieeofd,ee<,uipme„, etc. Curren. projects datas.^^^ 
403 comprises data co,«spo.di„g.oprojecua>atd,e vendor is cu™n..ywo,ki„go„.La,e„e. 
da. sec.»404 comprises da.correspondmg«.d>en™berot.imes.ta.*e vendor mrsseda 

dcadli.e,failed«>delivere,uipme«.ontime,e.c. Advantageously, module 156 may be 
accessedbybroadcastmodulelMotprooessor 108 inordertoobtain data inprior.0 
derennlningwhicb vendors sho«ldreceiveU,ebroadoas.ota„RFP,as is explainedinfte 

flowchart of Figure 7 below. 

KgureSisanow chart tatillustta.es*es,eps«a« performed in accordance wi* 
oneembodimenrofdre invention, inordertonaaureperformanceofaselectedvendorduringa 

project. It is noted *a. the steps that are illnstratcd in F.pre 2 are merely exemplary, and 
^.erorfewernnmberofstepsmaybeemployedinordertoaccomplishthesametactionsas 

aescribedhereiaAtstep 500, eventand date information is entered intone various fieldsot 

schedulmgdatastoragemodule 152. As previously mentioned, this data may be entered b, a 
p„chaser,orntayinsteadbe automatically populatedfromschednlingdatam.empla.ema.ger 
n,odulel22ornegotiationmodulell8.A.st^502,therclationshipsbetweeneventsise„tered 
in.o field 206 of schedulingdaUs.orage module 152. Alflroughflusdatamay be automadcally 
populated fiomdatainoO-er modules of processor,08,itisUl.ely to be enteredbyapurchaser. 

At step 504, even, data and corresponding da« information is en««d in even, field 301 
anddau field302,respectively,ofeven.notificaUonda.a storage module 154. inone 
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«bodim™., fields 301a„d 302 are a„.»adall,pop«la.edwi«.even.andda.eWo™«o„ 

ft„™eve„.a„dda.einfonnationftom fields 201 and 202 of scheduling data storage module 152, 
al.hou^U,isisno.,e,uired.Tl-eeve„.andda.einfom,afioun,ayal»been«redbyaperson 

manually. 

At step 506, the contact information for relevant persons is entered in contact data field 
303 and distribution data field 304 of event notification data storage module 1 54. In one 
embodiment, fields 303 and 304 are automatically populate wi4 contact information , such as 
e-m^laddresses, ftomteambuilder modules 110andU2ofprocessor 108. However,the 

contact and distribution data may also be entered by a person manually. 

At step 508, on ttte date stotcd in date field 302 of event notification data storage module 

,54, analytics module 120 of processor 108 transmits a notification message to the person 
identified in contactdata field 303. Tite notification message maytake any variety offonns,bu, 

preferably comprisesa,uery,askingti,econ.actpersonwhetheradeadlmerclatingtoa 
particular event will be, or has been, met. 

At step 510, the contact person receives the notification message. At step 512, the 
contact personprepares and transmits to processor lOSanotification response message. 

Preferably,the notification response message indicates whetheradeadlinerelati^ 
particular event willbe, or has been, met. If the contact person indicates that the deadline will 
notbemet, then the notificationmessagepreferablypermits the contact persontoprovideanew 

date on which the deadline will be met. 
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At step 514, processor 108 receives the notification response message from the vendor. 
At step 5 16, if the contact person has entered a new date, processor 108 updates actual 
completion date field 205 of scheduling data storage module 152. At step 518, processor 108 
reads field 206 in order to determine which other events are effected by the delay in completing 

^present event At step 520. for thoseevents.hata«efrected,processor 108 updates acmal 
start date and acnral completion date fields 203 and 205 in order to reflect the delay. 

At step 522, for each event that was effected by the delay, processor 108 locates the 
correspondingeve„tinfield301ofeventnotifica,iondatastoragcmodulel54andcon,actseach 

otthe per^ns in contact data field 303. Thus, each party that is effededby the delay is 
cognizant of the effect that the delay has on subsequent steps. 

According to one embodiment, analytics module 120 is also configured to generate a 
schedule interface,usingdataftomschedulingdatastoragemodulel52.Figure6isasample 

interface 600 that may be employe^ acc„*g to one embodiment of the invention, to display a 
projectschedulcTimeaxis 601 providesanindica«onoftime.whileeventaxis 602 lists 

variousevents, suchasthosepreviously discussed. Preferably,eventaxis 602 isautomatically 
populated by the event data of fields 201 or 301 shown in Figure 2 and 3, respectively. 

Tl,e start and completion date infomtation of fields 202 through 205 in Figure 2 is 
employed to generatetime lines correspondingtoeacheventinFi9.e 6. For instance, ifthe 

.artdateandcompleUondateforeventA,sJunelandlunelO,respectively,intrface600 
displaysatimelineforeventAwhichstartsatJunc 1 onhme axis 601 and ends at June 10 on 
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axis 601 . By maintaining inlerface 600, any interested party can view the schedule and the 
effects that a delay has on subsequent events, ta this case, pn>cessor 108 may contact effected 
vendors at st^ 522 otthe flowchart in Figure 5 by transmitting an e-mail message thereto 
advising Ihem to review the updated schedule interfece 600. 

As previously mentioned, vendor performance data storage module 156, which stores 
data corresponding to each vendor's performance, is employed to maintain a "report card" of 
each vendor's performance. Figure 7 is a flowchart that iUustmtes the steps that are performed, 
according to one embodiment of the invention, in order to maintain and use the data in vendor 
performance data. For tastance, at step 700, a vendor submits a response to a notification that a 
deadline has not been, or wiU be, missed. Thb response may corr«pond to the response that the 
vendor transmits to processor 108 at step 512 of the flowchart shown in Figure 5. 

At step 702, processor 108 populates vendor performance data storage module 156 of 
database 150. Ptwessor 108 may perfom, this step by storing in vendor performance data 
s«„age module 156 data corr^ponding to the missed deadline, such as adescription of the event 
tetwas missed, the datethisoccurre^thetotal length ofthedelay,e.c.Preferably,thisdata is 

stored in lateness data field 404 of vendor perfom«ce data storage module 156, as shown in 

Figure 4. 

At step 704. a purchaser prepares a new RFP, as explained in detail in Applicant's co- 
pending application identified as Attorney D«ket No. 878-0 1 1 , which, as previously indicated, 

is incorporated by reference herein. At step 706, processor 108 accesses broadcast population 
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module 1 14b. Processor 108 selects from broadcast population module 1 14b the vendors that 
sell or make the equipment which is the subject of the RFP. 

At step 708, processor 108 accesses broadcast rules module 1 14a, and enters the 
performance criteria which the purchaser requires of a vendor. For instance, this performance 
criteria may specify a maximum number of latenesses in previously-performed projects. Of 
course, the performance criteria may vary depending on the importance of a project. For 
instance, for a project that has a very tight deadline, the purchaser may enter a performance 
criteria which specifies that the maximum number of prior latenesses is zero. Thus, the only 
vendors that will receive the RFP for such a project will be those vendors that have no prior 
latenesses on previously performed projects. Similarly, for projects that do not have tight 
deadlines, the purchaser may enter a performance criteria which specifies a greater maximum 
number of prior latenesses. 

At step 710, processor 108 accesses vendor performance data storage module 156. 
Processor 108 checks the performance ratings of those vendors that were determined at step 706 
to make or sell that equipment that is the subject of the RFP. At step 712, processor 108 
determines which of these vendors meets the performance criteria selected in step 708. Then, at 
step 714, processor 108 broadcasts the new RFP to those vendors that meet the selected 
performance criteria. 

Of course, the present invention also contemplates that processor 108 may be employed 
to maintain other statistical data. For instance, processor 108 may be employed to generate 
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statistics relating to a vendor's efficiency or the number of RFP's that a particular vendor is 
participating in. Similarly, processor 108 may be employed to determine and display to 
interested users a purchaser's consistency of payment or any other type of statistical data 
relating to a purchaser which may be of interest to another party. 

While only certain features of the invention have been illustrated and described herein, 
many modifications, substitutions, changes or equivalents will now occur to those skilled in the 
art. It is therefore, to be understood that this application is intended to cover all such 
modifications and changes that fall within the true spirit of the invention. 
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